Netware Super Library

home *** CD-ROM | disk | FTP | other *** search

/ Netware Super Library / Netware Super Library.iso / app_note / an102b / an102b.txt next >

Wrap

Text File | 1991-12-11 | 33.8 KB | 753 lines

Running SQL Server in the NetWare Environment ▄ Running SQL Server in the NetWare Environment █ █ ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ Willie Tejada Corporate Integration Manager Systems Engineering Division ╔═════════════════════════════════════════════╗ ║ PgDn to Scroll or follow link for ║ ║ Table of Contents ║ ╚═════════════════════════════════════════════╝ Abstract: This Application Note explains how to install Microsoft's SQL Server v1.0 and v1.1 in a NetWare environment, using Novell's Named Pipes support for both OS/2 and DOS clients. It summarizes some of the issues involved in using Named Pipes for client-server applications and details the architecture of SQL Server under NetWare from both the OS/2 and DOS client perspective. It also gives a step-by-step procedure for manually installing SQL Server v1.0 (designed solely for LAN Manager networks) on a NetWare network. Finally, it includes some pointers for running SQL Server, querying a database, and diagnosing problems associated with Named Pipes connections. Running SQL Server in the NetWare Environment Contents Introduction The Client-Server Model Named Pipes Life Cycle of a Named Pipe Architecture of SQL Server Under NetWare NetWare Requester for OS/2 NetWare Requester for OS/2 Client Architecture NetWare DOS Named Pipes Extender Client Architecture NetWare Requester for OS/2 Installation Issues Tuning SPX NetWare DOS Named Pipes Extender Installation Issues Tuning the DOS Named Pipes Extender Maximum Machine Names Maximum Open Named Pipes Maximum Communication Buffers SQL Server v1.0 Installation SQL Server v1.1 Installation Operation Issues Starting and Stopping the SQL Server Diagnosing Problems with MAKEPIPE and READPIPE Querying the SQL Server Summary Appendix A: Bibliography Disclaimer Novell, Inc. makes no representations or warranties with respect to the contents or use of these Application Notes (AppNotes) or of any of the third-party products discussed in the AppNotes. Novell reserves the right to revise these AppNotes and to make changes in their content at any time, without obligation to notify any person or entity of such revisions or changes. These AppNotes do not constitute an endorsement of the third-party product or products that were tested. Configuration(s) tested or described may or may not be the only available solution. Any test is not a determination of product quality or correctness, nor does it ensure compliance with any federal, state or local requirements. Novell does not warranty products except as stated in applicable Novell product warranties or license agreements. Copyright (c) 1991 by Novell, Inc., Provo, Utah. All rights reserved. As a means of promoting NetWare AppNotes, Novell grants you without charge the right to reproduce, distribute and use copies of the AppNotes, provided you do not receive any payment, commercial benefit or other consideration for the reproduction or distribution, or change any copyright notices appearing on or in the document. Running SQL Server in the NetWare Environment Introduction In 1989, Novell included support for the Named Pipes application programming interface (API) in the NetWare Requester for OS/2. The following year, Novell added support for Named Pipes in the NetWare DOS Client Shell. This Named Pipes support makes it possible to run applications based on Named Pipes in the NetWare environment. Microsoft's (R) SQL Server is one such application. In most network configurations, SQL Server is installed as a LAN Manager service and runs as an OS/2 application along with other OS/2 applications such as Microsoft LAN Manager, IBM LAN Server, or 3+ Open. The SQL Server documentation fully describes the installation and use of the SQL Server in a LAN Manager environment. Microsoft has certified SQL Server for use in the NetWare environment. However, prior to SQL Server v1.1, the installation programs and manuals which accompanied SQL Server presumed installation into a LAN Manager environment. This Application Note examines the different components of NetWare and SQL Server, and explains how to install and configure these components in a NetWare environment. Running SQL Server in the NetWare Environment The Client-Server Model The client-server model expands the number of distinct pieces of applications software needed to support database activity from one to at least four. Traditional PC database management systems used the server both for data storage and as a distribution facility. Figure 1 shows four parts of a client-server database application. Part 1, the client front end, typically is responsible for such tasks as presentation, collection, and validation of data. This front end might be a custom application written to provide a simple-to-use graphical or text user interface. The front end accomplishes its tasks by passing SQL statements to part 2, the interface between the front end and the underlying network protocol. This network interface can facilitate network communications for the front end application. This part always looks the same to the front end, but must be customized to work with specific network protocols. Microsoft SQL Server uses the Named Pipes API as its network interface. Novell has provided the customization of the interface to the network protocol by providing Named Pipes support over Novell IPX/SPX through a Named Pipes driver and daemon supplied in the NetWare Requester for OS/2 and through a Named Pipes extender for DOS clients. (These components are discussed later in this AppNote.) Part 3 is analogous to part 2, but acts as the interface between the database engine and a particular network protocol. Part 4 is the database engine. It ultimately receives SQL statements generated by the client front end and responds to them. To establish a successful connection between the front end and the server, parts 2 and 3 must support the same network protocol. Running SQL Server in the NetWare Environment Named Pipes A basic understanding of Named Pipes may provide a useful background on how the various components of the SQL Server and NetWare fit together. Named Pipes is a high-level API for interprocess communications (IPC). Named Pipes provides a method for transferring data between different processes across the network or in the same machine. These functions have been part of OS/2 since v1.1 Standard and Extended Edition and do not require LAN Manager/LAN Server to be installed. As mentioned before, the use of Named Pipes shelters both front-end and server applications from the underlying transport protocol, allowing applications to run on many different networks. Life Cycle of a Named Pipe To illustrate how a server-based application works with Named Pipes, let's look at how a database server works on an application server using Named Pipes. Microsoft's SQL Server is an example of such an application. (Named Pipes is not required for server-based applications. Other server-based applications use IPCs such as Novell's IPX/SPX or NetBIOS to accomplish the same functions). Figure 2 steps through the life cycle of a Named Pipe. First, a named pipe is created on the server side with the DosMakeNmPipe API, and the pipe is given a name. Second, the server-based application must connect to the pipe using the DosConnectNmPipe API. The Named Pipe server is now in a listening state, waiting for a client to establish a connection and request its resources. Third, the client end connects to its end of the pipe by using the DosOpen API and submitting the name of the server and the pipe. The Named Pipe server receives the client's request and the connection is established. If the NetWare Requester for OS/2 is installed on each machine, the user must clarify which machine will be the Named Piped server and which will be the Named Pipe client. There is a distinction between the two: Named Pipe servers broadcast their machine name on the network; Named Pipe clients do not. Fourth, after both sides are connected, they can begin the DosRead, DosWrite, or DosTransactNmPipe dialogue. Lastly, when the dialogue is complete, the server calls the DosDisconnectNmPipe API, and the client performs the DosClose operation. The server can then execute another DosConnectNmPipe call and wait for the next client. Running SQL Server in the NetWare Environment Architecture of SQL Server Under NetWare Currently, the SQL Server is an OS/2 application and cannot run on a NetWare file server. To support SQL Server and other Named Pipes-based client-server applications, Novell added support for the Named Pipes API to both their OS/2 and DOS client services. This allows OS/2 computers to be set up as application servers and communicate in a peer-to-peer fashion with client programs running on other workstations. Figure 3 illustrates a typical SQL Server installation on a NetWare Network. Because of the peer-to-peer nature of the Named Pipes support, the NetWare server need not be present for the SQL Server to function. NetWare Requester for OS/2 The NetWare Requester for OS/2 is Novell's client software for OS/2 workstations. It allows OS/2 workstations to access and use resources on a NetWare file server. It also supports Named Pipes and NetBIOS communications. The NetWare Requester includes the following components. Component Description NetWare Spooler OS/2 print spooler LSL driver The link support layer (LSL) driver, part of Novell's Open Data-Link Interface (ODI) NIC driver An ODI-compliant network interface card Novell IPX Protocol Novell's Internetwork Packet Exchange (IPX) protocol stack SPX Protocol Novell's Sequenced Packet Exchange (SPX) protocol stack. This stack is optional, but required for Named Pipes support. Named Pipes Layer Named Pipes driver and daemon. Requires useof the SPX protocol stack. A "computername" parameter is required when loading the daemon to configure the OS/2 machine as a Named Pipes server. Requester NetWare requester drivers and daemon.Provides I/O redirection for file, printer, and serial devices to NetWare servers. NetBios Layer NetBIOS driver and daemon. Not required forNamed Pipes support. NetWare Requester for OS/2 Client Architecture Figure 4 illustrates the NetWare OS/2 Requester client architecture. The NetWare Requester services user requests, such as directory listings and logins, as well as application requests, such as file access or print service. OS/2 was designed to be an intelligent workstation operating system. This means that when the OS/2 kernel receives a call from an application or a user, it is capable of determining if the call is for a local or a remote service. If the call is local, OS/2 will execute the request at the workstation. Examples of local requests include accessing files on a local hard disk or printing to a local printer. If the call is remote, such as creating a file or listing a directory's contents, the OS/2 kernel passes the request to the NetWare Requester. When the NetWare Requester receives the call, it can do one of two things: send the request on its way to the file server or hand the request to the Named Pipes driver. If the call is a request for NetWare services (such as file or print access), the NetWare Requester translates the request into a NetWare Core Protocol (NCP) request. (NCP is the language spoken at the NetWare file server.) The NCP request is then passed on to Novell IPX, which takes care of the routing of information over the network. If the call is for Named Pipes, the NetWare Requester passes the call to NetWare's Named Pipes driver. Once Named Pipes has completed its function, it passes the call to SPX. (Notice the application's Named Pipes call is never translated into NCP.) SPX sits on top of Novell's IPX and guarantees packet delivery on the network. During run time, an OS/2 SQL Server client application makes calls to the DB-Library, a call-level host language interface. This collection of function and procedure calls provides an easy-to-use, uniform, consistent interface to the SQL Server for the C programming language. The DB-Library in turn makes calls to the SQL Server's NetLib interface for Named Pipes, which is implemented as a dynamic link library (DLL). The DBNMPP.DLL makes Named Pipe calls to the NetWare Requester, which passes the calls to the NetWare Named Pipes driver. The NetWare Named Pipes driver then makes use of Novell's SPX protocol to communicate with a SQL Server on an OS/2 application server. NetWare DOS Named Pipes Extender Client Architecture Figure 5 illustrates the DOS client architecture. The NetWare DOS shell program works with IPX and the network driver to convert a standalone DOS workstation to a network workstation. The NetWare DOS Shell is loaded into RAM when access to the NetWare file server is desired. The shell sits between the operating system (DOS) and the DOS client application. The shell intercepts DOS function requests (through interrupt 21h) and determines whether the request is for a local or NetWare service. If the call is a request for a NetWare services (such as file or print access), the DOS shell translates the request into NCP and uses the underlying Novell IPX protocol to route the request to the file server. Novell provides several other IPCs to the DOS client, including NetBIOS, Named Pipes, and the SPX guaranteed delivery transport. Client-server applications may use any of these IPCs. A DOS SQL Server client application uses Novell's DOS Named Pipes Extender (DOSNP.EXE), implemented as a terminate-stay-resident (TSR) program. As on an OS/2 workstation, an interface to the SQL Server's Named Pipes interface is required. Microsoft provides this static link library as a TSR program, DBNMPIPE.EXE. At run time, the DOS SQL Server client application makes calls to the DB-Library. The DB-Library in turn makes calls to the SQL Server NetLib interface for Named Pipes (DBNMPIPE.EXE). The DBNMPIPE.EXE TSR makes Named Pipes requests that are trapped by Novell's DOS Named Pipes Extender (DOSNP.EXE) TSR. As in the OS/2 workstation sequence of events, the Named Pipes calls are passed directly to the DOS Named Pipes Extender, which then uses the underlying Novell IPX/SPX protocols to route the request to the Named Pipes server. (Notice that the DOS SQL Server client application Named Pipes calls are never passed through the NetWare DOS shell for translation into NCP requests). Running SQL Server in the NetWare Environment NetWare Requester for OS/2 Installation Issues Follow the procedures for installation provided in the NetWare Requester for OS/2 installation manual, making the following modifications to the OS/2 CONFIG.SYS file for SQL Server operation. Since the default lines added to CONFIG.SYS for the OS/2 Requester do not load the SPX protocol stack or Named Pipes support, you must do this manually by uncommenting certain lines. For example, you would remove REM from these lines: REM DEVICE=C:\directory\SPX.SYS REM RUN=C:\directory\SPDAEMON.EXE REM DEVICE=C:\directory\NMPIPE.SYS REM RUN=C:\directory\NPDAEMON.EXE "computername" Note that the Named Pipe support layer in the OS/2 Requester is installed after the Novell IPX and SPX stacks are loaded. When uncommenting the lines to load Named Pipes support, it is important to provide a unique "computername" to the Named Pipes daemon. This allows the workstation to act as a Named Pipes server and makes the server visible on the network for programs like the SQL Server System Administration Facility (SAF). It also allows NetWare to imitate the server naming scheme used by LAN Manager and indicates that applications will be creating and sharing Named Pipes at this application server. The OS/2 requester diskette for version 1.21 contains two DLLs in a \SQL directory that emulate a small subset of Microsoft LAN Manager API calls. In particular, these DLLs are required to support the extended functionality of the SAF. Note that these DLLs are provided specifically for SQL Server applications and so are not automatically installed with the OS/2 Requester. You will need to check that these DLLs are installed in the OS/2 LIBPATH before using the SAF on an OS/2 server or workstation. A README file in the \SQL directory clearly explains what needs to be done. Tuning SPX The NET.CFG file can include the following SPX parameters under the "Protocol Stack SPX" heading: Protocol Stack SPX Socket "count" Sessions "count" (Note: replace count with a value 256) SPX Abort timeout "number" SPX Verify Timeout "number" SPX Listen Timeout "number" SPX Retry Count "number" In order to get the maximum number of Named Pipes connections on the OS/2 application server, increase the SPX sessions parameter from its default of 16 to the maximum of 256. If there are not enough SPX sessions available, the OS/2 Requester issues the following error message: NPDAEMON:Error SPX listen for connection For a complete listing of NET.CFG parameters, refer to the installation guide under "Reconfiguring the OS/2 Requester." Running SQL Server in the NetWare Environment NetWare DOS Named Pipes Extender Installation Issues Installing the DOS Named Pipes support layer is straightforward. The Novell OS/2 Requester diskette for version 1.21 contains a \DOSNP subdirectory that contains the Named Pipes TSR (DOSNP.EXE). Copy this TSR to the network directory on the local workstation (or to the boot directory on the NetWare file server for remote-boot systems). In the AUTOEXEC.BAT file, insert a line to load DOSNP.EXE immediately after the Novell IPX driver and the NetWare Shell. The network software must be loaded in the following order: o IPX.COM o NETx.COM o DOSNP.EXE o DBNMPIPE.EXE (provided with SQL Server) Tuning the DOS Named Pipes Extender To fine tune the NetWare DOS Named Pipes Extender, set the following options in the SHELL.CFG file. (You can rename this file NET.CFG.) Maximum Machine Names The NetWare DOS Named Pipes Extender maintains a table of Named Pipes servers on the network. The maximum machine names option allows the size of this table to be adjusted. NP MAX MACHINE NAMES = number Replace number with the desired number of Named Pipes servers. Minimum = 4 Maximum = 50 Default = 10 Maximum Open Named Pipes This option specifies the number of pipes that can be opened. This number is the total number of open pipes. NP MAX OPEN NAMED PIPES = number Replace number with the desired number of open named pipes. Minimum =4 Maximum = 128 Default = 4 Maximum Communication Buffers The NetWare DOS Named Pipes Extender requires communication buffers for transmitting data to and from the Named Pipes server. This option specifies the number of buffers. NP MAX COMM BUFFERS = number Replace number with the desired number of communication buffers. Minimum = 4 Maximum = 40 Default = 6 NOTE: You should specify a minimum of two buffers per open pipe; however, as the number of pipes increases, this number can be reduced. Running SQL Server in the NetWare Environment SQL Server v1.0 Installation The installation program for Microsoft SQL Server v1.0 was designed strictly for LAN Manager networks. You cannot use the setup program that accompanies the SQL Server v1.0 if you are installing on a non-LAN Manager network. You must perform manual installation of the SQL Server v1.0. You'll need at least 8MB of RAM and at least 20MB of free disk space on your hard disk. Here's how to do it. 1. Create the SQL Server directory structure by creating the following directories (use the appropriate drive letter): C:\SQL C:\SQL\BINP C:\SQL\DATA C:\SQL\DLL C:\SQL\INSTALL C:\SQL\LOG 2. Copy the SQL Server files from the OS/2 release diskettes. o Copy all .EXE and .HLP files to the C:\SQL\BINP directory. o Copy DBLIBP.DLL and MSHELP.DLL to the C:\SQL\DLL directory. o Copy all .SQL files to the C:\SQL\INSTALL directory. Don't worry about the .C, .H, and .LIB files for now. They are part of the DB-Library support package, and can be installed directly on a workstation where C language programming will be done. 3. Create the SQL Server executable. The SQL Server is too big to fit on one diskette. You must concatenate two SQLSERVx.EXE binary files into one. To do this, change to the C:\SQL\BINP directory, then type: COPY SQLSERV1.EXE /b + SQLSERV2.EXE SQLSERVR.EXE /b <enter> You may delete the component files once they are joined. 4. Modify your PATH and LIBPATH variables. Add C:\SQL\BINP to your OS/2 PATH statement and C:\SQL\DLL to our LIBPATH statement in CONFIG.SYS. Reboot if necessary to allow the changes to take effect. 5. Create the SQL Server master database device file. Change to the C:\SQL DATA directory. This is where you will create the SQL Server master database device (an OS/2 file which contains SQL Server databases). Issue the following command: BLDMASTR /dMASTER.DAT /s5120 /C <enter> The first parameter is the name of the file and the second parameter is the size in 2KB pages (5,120 is the minimum size but you may use a larger number if you like). Note that switches for the SQL Server utilities are case sensitive (for example, /d means something different from /D). The /C switch instructs BLDMASTR to create a server that is not case sensitive (the default is case sensitive). This cannot be changed later. Omit this switch if you want to have a case sensitive database. 6. Start the SQL Server. You are now ready to start the SQL Server for the first time. It must be running to complete the remainder of the installation. From the OS/2 prompt, type (on one line): SQLSERVR /d C:\SQL\DATA\MASTER /e C:\SQL\LOG\ERROR.LOG <enter> Remember to provide the complete path names to the master database device and error logs. For more information on starting and stopping the SQL Server, see "Operation Issues" after the following section. 7. Build the Master, Model, and Pubs databases. Run another copy of the OS/2 command processor (the current screen group should be tied up by the SQL Server). Change to the C:\SQL\INSTALL directory. You are now ready to execute the TRANSACT-SQL build scripts that create the complete SQL Server database environment. From the OS/2 prompt, issue the following commands in this order: ISQL /Usa /P < INSTMSTR.SQL <enter> ISQL /Usa /P < INSTMODL.SQL <enter> ISQL /Usa /P < INSTPUBS.SQL <enter> These commands will each take a few minutes to execute. NOTE: If you are performing a remote install, it may be necessary to specify the name of the server on the ISQL command line. Use the /S switch to do so. For example, if the name you passed to the NPDAEMON.EXE program in the CONFIG.SYS was SQL_SERVER, use the following command line to run the INSTMSTR.SQL script: ISQL /Usa /P /SSQL_SERVER < INSTMSTR.SQL <enter> Running SQL Server in the NetWare Environment SQL Server v1.1 Installation Installing SQL Server v1.1 into a NetWare environment is made much easier by the use of the SQL Server SETUP program v1.1. In a normal installation, SETUP still assumes the existence of a LAN Manager environment, and will attempt to install SQL Server as a LAN Manager service. At the beginning of the SETUP routine, indicate that you want to install the database itself. You will then be asked if you want to install SQL Server on a network or on a standalone system. To install the SQL Server 1.1 on a non-LAN Manager LAN such as NetWare, you must select the standalone install option. Standalone installation of the SQL Server is fully documented in the Microsoft SQL Server Installation Guide. Running SQL Server in the NetWare Environment Operation Issues Starting and Stopping the SQL Server You can start the SQL server either directly from the OS/2 command line or by adding the SQL Server as a program item under the OS/2 Program Manager. Remote starting and stopping of the SQL Server is not possible due to the lack of the LAN Manager NET START and NET STOP commands. The SQL Server can either occupy a screen group or be run as a detached process. To start SQL Server in its own screen group, use the following command: sql -d c:\sql\data\master.dat -e c:\sql\log\error.log <enter> To start SQL Server as a detached OS/2 process, use the following OS/2 DETACH command (typed on a single line): detach sqlservr -d c:\sql\data\master.dat -e c:\sql\log\error.log <enter> The -d parameter is the fully qualified pathname of the SQL Server Master database device, which is usually installed in the \SQL\DATA directory. This is the bootstrap device that contains the SQL Server master database as mentioned earlier in the SQL Server v1.0 installation procedure. The -e parameter is an optional path name of the error log. If this parameter is not supplied, output generally goes to the display (this is not visible when the SQL Server is running as a detached process). To stop the SQL Server, you can use the SAF menu option or the TRANSACT-SQL SHUTDOWN command. To create an OS/2 command file which will stop the SQL Server automatically, first create the following TRANSACT-SQL script file with a text editor. SHUTDOWN GO Name this file SHUTDOWN.SQL and save it in the \SQL\BINP directory. Then create the following OS/2 command file: @ECHO OFF ISQL -Usa -P,<sa-password. -i c:\sql\binp\shutdown.sql Save this file under a convenient name, such as STOPSQL.CMD, somewhere in your OS/2 PATH. To shut down the SQL Server, simply type "stopsql" at the OS/2 prompt. Complete documentation of the use of the ISQL utility and TRANSACT-SQL scripts can be found in the Microsoft SQL Server Administrator's Guide and Microsoft SQL Server Language Reference. Diagnosing Problems with MAKEPIPE and READPIPE A useful method to isolate network problems is to use two diagnostic programs that are provided with SQL Server: MAKEPIPE.EXE and READPIPE.EXE. These utilities are not described in the SQL Server documentation. On the SQL Server machine, run MAKEPIPE.EXE, which (as the name implies) creates a named pipe. MAKEPIPE takes no parameters. From a second OS/2 machine (or second screen group on the same machine), run READPIPE.EXE. This program takes two parameters: the computer name of the machine creating the pipe (in the NetWare environment this would be the computer name given after the NPDAEMON.EXE parameter in the CONFIG.SYS file) and a string of data. Here is the format for this command: READPIPE /s[SERVER_NAME] /d[DATA_STRING] NOTE: Do not put a space between the /s and the server name, or between the /d and the data string. If the Named Pipes server and Named Pipes client are working properly, the screens of both machines should display the data sent and the data received. This is a simple test to see if Named Pipes is working. Querying the SQL Server You can perform a simple query of the SQL Server to test the operation of your SQL Server. Here's how: 1. Boot the SQL Server machine and start the SQL Server software. 2. Boot an OS/2 workstation with the NetWare Requester for OS/2 (with SPX and Named Pipes enabled). 3. Start the System Administration Facility by typing: SAF <enter> 4. Press <enter> at the title screen. 5. Type the name of your SQL Server and press <Tab>. (Note: This is the "computer name" given at the time the NPDAEMON.EXE is executed in the CONFIG.SYS file.) "computer name" <tab> 6. Type the System Administrator user name: user name <enter> 7. After the workstation attaches to the SQL Server, select the PUBS database by entering: USE PUBS <Ctrl> <E> 8. Clear the screen by entering: <Ctrl> <N> 9. Enter a query. For eample: SELECT * FROM AUTHORS <Ctrl> <E> 10. View the results of the query by typing: <Ctrl> <F> 11. Exit the SAF by executing the following keystrokes in this order: <Alt> <F> <X> Running SQL Server in the NetWare Environment Summary With the introduction of SQL Server v1.1, Microsoft has made a conscious decision to separate the database functions from the network functions. Unlike SQL Server v1.0, SQL Server v1.1 loads the network protocol functions as a separate dynamic link library (DLL). This DLL implementation paves the way for developers to use network interfaces other than Named Pipes (such as Novell IPX/SPX). Novell will continue to support industry-standard interfaces such as Named Pipes, NetBIOS, TLI/Streams, and sockets, allowing distributed applications based on these interfaces to function in a NetWare environment. Running SQL Server in the NetWare Environment Appendix A: Bibliography Books Microsoft LAN Manager: A Programmer's Guide version 2, Microsoft Corp., 1990 Microsoft LAN Manager: Programmer's Reference version 2, Microsoft Corp., 1990 A Technical Overview of SQL Server, Advanced Consulting Group, Ashton-Tate 1988 Technical Documents Using Microsoft SQL Server on a NetWare Network, Microsoft Corp., 1989 Installing SQL Server 1.0 Under Novell NetWare, Ashton-Tate Professional Services Division, 1989 Articles Bolt, Robert, "Battle of the DataBase Servers", LAN Technology (January 1991) Editor's Note: The author accepts written feedback at FAX (801) 429-5511.